[Enhacement] Extrapolate Linestring rate and distance support

[latot]

Hi all, I think would be great to can extrapolate linestrings, for this case I'm thinking when we want to extend a linestring, there is a stackoverflow with a good answer for this:

​https://gis.stackexchange.com/a/269524/213252

It proposes extend a segment where the final length is actual_length*rate_length + constant_rate. I think is a good concept.

I'll extend the concept, instead of just "extrapolate" a linestring in the end and start, we can extrapolate a segment, like ST_SetPoint, where we can extend a segment specifying the segment id (0 for first -1 for the last one). This is a way to do it, but I don't know if is the best concept for the function maybe is too general, but it is flexible.

So, here a summary I think would be fine to have before start coding.

Extrapolate the first and last segment of a linestring, or just extrapolate the "i" segment, their start/end points?

What would be the extrapolation of a multilinestring?

And a last thing, usually the easiest one is the geometry extrapolation, just the line equation, while the geography extrapolation is not trivial and does not works the method posted in stackoverflow, would be great have both of them.

Thx!

[mdavis]

Agreed, this would be a good extension (pun intended).

One way to do this is to enhance ​ST_LineSubstring to allow the startFraction and endFraction values to lie outside the range [0,1]. If startFraction is < 0 the first segment of the line is extended backwards. If endFraction is > 1 the last segment of the line is extended forwards.

This could be extended to MultiLineStrings, by letting the length fractions apply to the entire MultiLineString, keeping the order of the element lines.

[latot]

I agree that would be a great way to do it, I would be only worried about the name convention, now would not be only substring.

With the actual params, ST_LineSubstring can pick the rate, the constant is useful too, but I don't know if put that inside the function too.

The constant part is pretty useful too, specially if you need extend a linestring over some extent, will small linestrings the rate only does the calc more complex, while a constant do it simpler.

[mdavis]

Perhaps an alternate name would be ST_LineExtend. Although it can be difficult to invent names which precisely describe semantics, so sometimes it's fine to just have a function with broader scope than the name implies, and simply describe the behaviour in the documentation.

[mdavis]

Replying to latot:

With the actual params, ST_LineSubstring can pick the rate, the constant is useful too, but I don't know if put that inside the function too.

The constant part is pretty useful too, specially if you need extend a linestring over some extent, will small linestrings the rate only does the calc more complex, while a constant do it simpler.

Are you suggesting adding an option to specify that the start and end parameters are absolute lengths, rather than a fraction of the line length?

This could be done with an option flag, or with a new function (say ST_LineSubstringLen).

[latot]

Yay!

[pramsey]

I think line extension is a distraction, since the core operation here (in cartesian and geographics) is projection. Basically, a function like ​https://postgis.net/docs/ST_Project.html only with two arguments and a distance. You could build it yourself easily enough from parts already lying around.

ST_Project(ST_StartPoint(line), distance, ST_Azimuth(ST_StartPoint(line), ST_EndPoint(line))

So, I can see a convenience function like

ST_Project(startpt, endpt, distance) returns point

would allow people to choose points however they like with existing functionality and support both geometry and geography.

[Paul Ramsey <pramsey@…>]

In 759da8e/git:

Add ST_LineExtend for users who want slightly longer lines.
Supports things like extending for noding and so on.
Closes #5267